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Abstract 

In code certification the code consumer publishes a safety pol- 
icy and the code producer generates a proof that the produced code 
is in compliance with the published safety policy. In this paper, a 
novel viewpoint approach towards an implementational re-use oriented 
framework for code certification is taken. It adopts ingredients from 
Necula’s approach for proof-carrying code, but in this work safety 
properties can be analyzed on a higher code level than assembly lan- 
guage instructions. It consists of three parts: (1) The specification lan- 
guage is extended to include generic pre-conditions that shall ensure 
safety at all states that can be reached during program execution. Ac- 
tual safety requirements can be expressed by providing domain-specific 
definitions for the generic predicates which act as interface to the envi- 
ronment. (2) The Floyd-Hoare inductive assertion method is refined 
to obtain proof rules that allow the derivation of the proof obliga- 
tions in terms of the generic safety predicates. (3) A meta-interpreter 
is designed and experimentally implemented that enables automatic 
synthesis of proof obligations for submitted programs by applying the 
modified Floyd-Hoare rules. The proof obligations have two separate 
conjuncts, one for functional correctness and another for the generic 
safety obligations. Proof of the generic obligations, having provided 
the actual safety definitions as context, ensures domain-specific safety 
of program execution in a particular environment and is simpler than 
full program verification. 
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1 Introduction 


Code certification provides a mechanism for insuring that a host, or code 
consumer, can safely run code delivered by a code producer. The host spec- 
ifies a safety policy as a set of axioms and inference rules. In addition to the 
program, the code producer delivers a certificate, ie. , a formal proof of safety 
expressed in terms of those rules that can be easily checked. AutoBayes (cf. 
[FSW02]) addresses the problem of combining automatic code generation 
from high-level specifications together with code certification. AutoBayes 
automatically generates imperative programs for data analysis that are an- 
notated with pre-conditions, post-conditions, loop invariants, and with some 
other annotations from compact high-level specifications. The process of 
proving functional correctness is different from proving safety of program ex- 
ecutions. When analyzing safety, environmental constraints that cannot be 
anticipated while the program is being developed and the states that can be 
reached during execution need to be taken into account. The code consumer 
defines exactly under what conditions execution is considered to be safe. 

This paper applies the viewpoint architecture devised by the author (cf. 
[Eus99]) to enable practical implementations for automated certification of 
annotated programs. Viewpoints (VPs) are independent intermediate soft- 
ware components, introduced for the loosely coupling of multi-paradigm 
knowledge sources. Generic methods are derived domain-independently with 
respect to associated generic theories. A VP specifies how domain-specific 
knowledge sources correspond to a generic theory. Using a VP as application 
specific context, any associated generic method can then be specialized for 
the particular domain. The framework adopts ingredients from Necula’s ap- 
proach for proof-carrying code (cf. [Nec97]). A safety policy is considered to 
consist of the safety rules and the interface, but in this work generic safety 
properties are analyzed on a higher code level rather than assembly language 
instructions. A three-stage approach is taken. Firstly, in this paper, the 
safety interface to the environment is analyzed in terms of generic safety pre- 
conditions. Application-specific safety requirements are expressed by pro- 
viding them as instantiations of the generic safety predicates. Secondly, the 
Floyd-Hoare inductive assertion method is extended and modified to yield 
a set of verification rules that especially state for all operations the associ- 
ated generic safety pre-conditions. Thirdly, a meta-interpreter is designed 
and implemented that synthesizes proof obligations for annotated programs 
by applying the modified proof rules. The obligations have two separate 
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conjuncts, one for functional correctness and another for the generic safety 
conditions. 

Having decoupled the definition of the safety interface from the safety 
rules provides a flexible re-use oriented framework for the analysis of vari- 
ous domain-specific safety policies. It is exemplified analyzing a basic but 
nontrivial level of safety, including array bounds, undefined values, and finite 
domain constraints in a way that is simple, efficient, and - most important 
- easy to plug into the existing AutoBayes architecture. When the proof 
obligations are generated, the user can use all the power of the underlying 
simplifier and theorem prover to resolve the correctness obligations. Once the 
correctness proofs are successfully done, it is guaranteed that the synthesized 
programs always satisfy the functional correctness requirements. Correctness 
proofs can be re-used in a variety of environments. In addition, a proof of the 
generic obligations, having provided the actual safety definitions as context, 
ensures domain-specific safety of program execution in a particular environ- 
ment. These proofs can be automatically performed using highly specialized 
tools like constraint solver or type checker and, therefore, the whole process 
is simpler than full program verification. 

The remainder of this paper is organized as follows. Section 2 gives an 
overview of the certification framework. Section 3 exemplifies the concept of 
safety interfaces. Section 5 presents the design of the meta-interpreter that 
enables the automatic synthesis of generic safety conditions and demonstrates 
it on examples. Finally, this framework is compared with related work. 

2 Overview of the Certification Framework 

Proof-carrying code is a framework for verifying the safety of machine-lan- 
guage programs with a machine-checkable proof. Following Necula (cf. [Nec97]) 
the idea is that the code consumer defines and publishes a safety policy. 
The code producer constructs in the stage named code certification a formal 
proof that a program respects the published safety policy. First it computes 
its safety predicate using verification-condition generation rules. The safety 
predicate is a predicate in first-order logic with the property that its valid- 
ity is a sufficient condition for ensuring compliance with the safety policy. 
The code consumer downloads both the code and the proof. Then, it checks 
whether the safety proof is a valid proof of the safety predicate. The code 
consumer executes the machine-code without performing additional run-time 
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Figure 1: Overview of the Certification Framework 


checks. 

This paper presents a generic framework for verification condition gen- 
eration that doesn’t depend upon particular safety requirements. For its 
realization, the viewpoint concept which was devised by the author to fa- 
cilitiate the design of re-usable generic methods is being applied. Adopting 
Necula’s ([Nec97]) approach, a safety policy consists of two main compo- 
nents, the safety interface and the safety rules. The safety interface specifies 
the requirements for the execution of program steps in interaction with the 
environment of interest to be secure. While Necula’s verification condition 
generator embodies a specific abstract machine model reflecting the crucial 
safety parameters of the anticipated execution environment, the proposed ap- 
proach generalizes the process by employing additional generic safety pred- 
icates in the verification condition generator. These virtual generic safety 
pre-conditions ensure that the state after operator application and the state 
before is safe. They are computed and propagated during verification condi- 
tion generation, however no run-time checks are required. The generic safety 
predicates can be instantiated providing the safety interface determining the 
concrete situational safety requirements of the executing environment as a 
viewpoint. Based upon these extended verification rules, a meta-interpreter 
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is devised that enables the computation of proof obligations for submitted 
annotated programs. The obligations have two separate conjuncts, one for 
functional correctness and another for the generic safety obligations. Au- 
tomated theorem provers can be used for verifying functional correctness. 
However, first-order theorem provers are not well suited for type checking, 
algebraic simplifications, numeric and symbolic arithmetic calculations which 
naturally arise from considerations about safety of imperative programs. In 
most cases, the particular safety obligations can be easily discharged by spe- 
cialised and efficient analysis tools. Figure 1 depicts the resulting architec- 
ture. 

2.1 Specification and Example Scenario 

AutoBayes synthesizes programs which are imperative programs constructed 
of declarations and assignments, conditionals, loops, iterations, sequences 
and block statements that operate on multi-dimensional arrays. Programs 
are annotated with logical assertions in a Floyd-Hoare logic style, such as 
pre-conditions, post-conditions and loop invariants. Pre-conditions specify 
the valid values of the input parameters. Post-conditions specify the output 
and the (possibly modified) environment. Invariants state properties that 
are true at each iteration in a loop. Annotations support design and verifica- 
tion of software units. The code is in the form of an intermediate language. 
The specification terms are Boolean expressions with the addition of quan- 
tifiers, arbitrary user-defined predicates and basic types. The syntax of the 
specification language is summarized in Figure 2. 

To illustrate the proposed generic framework for safety certification, the 
following demonstration scenario is considered. The program in Figure 3 is 
encoded using a pseudo language. It is intended to abstract a Javascript pro- 
gram which sequentially selects an array of images according to their width 
and height and encodes the selection as HTML code, which in turn causes 
the placement of these pictures into a display area while being interpreted by 
a browser. The actual display depends on the execution environment as the 
computer platform, screen resolution or the used browser. In one environ- 
ment, the generated display may look as it was designed to be, taking another 
environment, the image display created with the same program can be com- 
pletely different or sometimes the browser doesn’t show anything at all. An 
execution environment is considered to be unsafe, if at some stage during 
interpretation images or parts of them disappear. The execution can be re- 
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expr ::= x\e\ + e 2 + . . . + e n \ e i ~ e 2 1 ei * e 2 |ei e 2 \ substitute^, e)| 

assign (a, ei, e 2 )| access (a, e)| err or, where e* is of type Expr 

r : int\bool\array(r, e)\ array(r, ei,e 2 ) 

true\false\Pi A P 2 jPi => P 2 |Vx : P s j3x : P x 

e i = c 2 1 'e 2 l^i > e 2 |ei < e 2 |e : t| 

safejassign{x , e)|sa/e_expr(ei)|sa/e_assign(a, e 2 , e 3 )| 

sa/e_access(a, e 3 ), where Pi is of type Predicate 

l::= ANNJNV(P,{x 1 ,...,x r }) 

a ::= Prog : (PPP = P x , POST = P 2 ) 


Figure 2: Syntax of the Assertion Language 


garded as safe, if the subsequent layout process yields the intended results. 
More precisely, a display area is defined as 0 < x < width , 0 < y < height , 
where width and height shall be integer constants, taking the upper left cor- 
ner as global origin. The definition of the size shall be part of the safety 
specification. However, size measures can be different depending on the cur- 
rent environment. Whereas the size of the display area could be specified 
using decimal measures, normally, script programs suppose sizes to be stated 
in pixels. Further on, it is supposed that the behavior of the execution envi- 
ronment is characterized by known system parameters and the actual layout 
at each stage during execution can be computed as combination of system 
parameters and values for program variables. However, at the time when the 
program is being developed, the behavior of the target execution environment 
is unknown because system parameters are subject to dynamic change. In 
this demonstration scenario, it is supposed that at all stages during display, 
a context-dependent relative origin can be determined. Its coordinates are 
described in relation to the top left corner of the display area. The browser 
positions the image taking this relative origin as top left corner leaving a 
margin at the left and upper border of the display area. After having as- 
signed a single image to the display array, the context-dependent relative 
origin is re-computed. 
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/idth 


PRE={true}- ; PROC (place-images)= { 
DECLS{input : array (images , gif ,2) , 
output: array (d_area,gif ,2) , 
local: scalar (i_width, integer) , 

scalar (i_height , integer) } 
STMTS{i_width : =150*2 ; i_height : =350 ; 

d_area(0) : =access (images , 2) ; 
d_area(2) : =access (images , 1) ; 
d_area(l) : =access (images , 0) }} ; 
P0ST={exists im: access (d_area,2)= 
assign (images ,0 ,im) } 




non— visible internal margin 
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0 c Figure 4: Context-dependent In- 
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terpretation 


2.2 Safety 

To analyze safety of embedded systems, it is necessary to define the legal 
states and actions, to show that the initial states are safe and to analyze 
the conditions under which the defined actions transform legal states into 
legal states. Technically this analysis is done by pre-condition analysis (cf. 
[Hei96]). [HCEH96] describes a framework for incorporating safety require- 
ments into operational Z specifications of software for embedded systems. 
Their approach is to produce additional pre-conditions which restrict the ap- 
plicability of operations. Operations may be applied to a given state only if 
it leads to a safe successor state. In this work, this technique is translated to 
analyze safety in addition to functional correctness of program executions. 
The Hoare semantics is refined by considering the various states program 
and additional environment variables can take during program execution us- 
ing a trace semantics (cf. [CouOl]). A program execution is a sequence of 
states, starting from an initial state for which the pre-condition is true, then 
moving from one state to the next and resulting in a final state which either 
satisfies the post-condition or is incorrect, assuming the program execution 
is terminating. A distinction is made between safe and unsafe states. A 
program execution is considered to be safe if and only if each computation 
of program and environment variables at each state during the execution 
complies with the host-provided domain-specific safety policy. It is supposed 
that rules of safe programming practice and the safety properties that a pro- 
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gram should satisfy can be specified by abstract types. Safety is considered 
as type correctness of variables and operator applications that must hold in 
all states during the program execution. 

The basic idea of safety checking is then to show that, firstly, the initial 
states are safe. This requires checks performed by the program that the pre- 
condition is true for the initial values and which is outside the scope of this 
paper. Secondly, the input arguments for operator application are safe with 
respect to its signature. Thirdly, operator application results in a safe state. 
In order to achieve a formal safety model, the definition by Necula and Lee 
(cf. [NL98]) is extended. A safety policy consists of two main components, 
the 

• Interface description , which is the boundary between the foreign soft- 
ware code and the code consumer. It contains a description of the for- 
mal type parameters for which syntax and semantic safety constraints 
can be given. 

• Safety rules , which describe all authorized operations and their associ- 
ated safety pre-conditions. 

The generalized safety policy consists of a viewpoint and generic safety rules. 
The following subsections discuss these two components in more detail. 

2.3 Viewpoints as Extension of Interface Descriptions 

It is widely accepted that precise interface descriptions make it easier to de- 
velop complex software systems from software components by controlling and 
structuring the dependencies between them. The interface is first specified, 
then the software which satisfies or uses the interface description is imple- 
mented. In this framework, the meaning is slightly different. An interface is 
an abstract meta-level description that specifies the safety requirements that 
should hold for the interactions between the foreign code and its environ- 
ment. During the certification process, it is formally verified that the given 
code conforms to its interface description. A safety interface is defined by 
a list of variable and type declarations, ie. the signature, against which the 
code will be certified. Whenever a type is declared, it can be attached safety 
axioms in the form of algebraic expressions or constraints. Type declarations 
define the states to be safe and the data-representation axioms to be pre- 
served. The interface may include descriptions which variables are initialized 
in the beginning. 
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In this paper, the viewpoint framework (cf. [Eus99]) is being applied to 
make domain-specific safety requirements accessible for generic verification. 
Generally, the starting point are generic predicates and their logical axioma- 
tization. Generic methods are derived in terms of the generic predicates. A 
generic method is then specialised to the environment of interest by providing 
the viewpoint as context. A viewpoint specifies how an abstract generic the- 
ory relates to a particular domain. It consists of rules which provide domain- 
specific definitions for the generic predicates such that the abstract properties 
remain valid. Analyzing safety, generic requirements are stated in terms of 
the generic safety predicates safe-expr, safe-assign. safe-expr{expr ) is a 
generic safety condition with the intended meaning that for all admissible 
inputs the evaluation of expr doesn’t cause an error. The intended meaning 
of safe-assign is, the safety condition is provable only if assignment leads to 
a safe successor state, provided that the state before assignment is safe. It is 
up to the actual safety policy to define the meaning of these generic safety 
predicates. Examples are discussed in Section 3. 

2.4 Extending the Pre-Condition for Generic Safety 

Hoare (cf. [Hoa69]) introduced the notation {Pre}Q{Post} for partial cor- 
rectness where Pre and Post are predicates specifying the pre-conditions and 
the desired result, respectively, for program Q. That is, if the assertion Pre 
is true before initiation of a program Q 1 then assertion Post will be true when 
it completes execution. Hoare presented the necessary axioms and inference 
rules for reasoning about programs written in a simple imperative language. 
Using Hoare Logic, a proof of {Pre}Q{Post.} is a sequence of sentences, the 
first of which is {Pre}Q{Post}, and each sentence is either a Lemma to be 
proven in the underlying logical system or a simpler sentence of the form 
{Pre'}Q' {Post 1 }. Each sentence in the sequence is derived from a previous 
line by applying a proof rule. The difficulty with this approach is that it is 
not clear how one determines the Lemmas to automate the process. 

This problem is solved using Floyd-style verification condition generators 
(VCGs), such as cf. [ILL75]. To build a VCG the axiomatic Hoare rules are 
reformulated to produce a deterministic set of rules that generate subgoals 
and ultimately verification conditions. The standard approach of verifying 
loops using Floyd-style VCGs involves introducing loop invariants explicitly, 
which is a challenge for any theorem-proving technique and often requires 
user intervention. Programs automatically synthesized by AutoBayes are 
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annotated with loop invariants and a standard VCG allows to automate 
the process of producing verification conditions for proving programs correct 
with respect to their specifications. These verification conditions can then 
be resolved, dependent on the underlying logic, possibly with the aid of 
an algebraic simplifier or theorem prover. Functional correctness doesn’t 
necessarily include safety of program execution. For example, the annotated 
example program in Figure 3 could be proven correct by applying the Hoare 
verification rules. However, program execution in a particular environment 
can be unsafe. In this simplified example, the faulty verification can be 
avoided by further assertions that attach domain-specific safety properties to 
single program statements. Generally, the hard encoding of safety obligations 
is a very tedious task. Moreover, such an approach is very unflexible. Each 
time when the safety requirements change, safety annotations need to be 
re-generated from scratch. 

In this paper, the standard Floyd-style rules for VCG are extended to 
cover safety of program executions. A meta-interpreter then allows to au- 
tomate the process of producing proof obligations whose validity ensures 
programs functional correct and safe to execute with respect to their spec- 
ifications. All security-related operations the program can perform at all 
stages during program execution are considered. When the VCGen sees a 
safety-related operation that changes the state of variables, a generic safety 
condition is launched and used to strengthen the pre-condition. 

3 Safety Viewpoints 

The basic idea is to identify rules of safe programming practice concerning 
safety properties on various levels (hardware, runtime, applications), formal- 
ize them, and making these descriptions accessible for a generic approach 
towards safety verification through a safety viewpoint T sa j e , consisting of the 
signature, axioms and lifting rules which provide domain-specific definitions 
for the generic safety predicates. 

3.1 Type Declaration/Signature 

Many software bugs come from small mistakes. Programmer sometimes for- 
get to initialize a variable or omit an argument to a function. If a loop misses 
the incrementation step, it will loop forever. Invalid arithmetic operations, 
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e.g., division by zero, may yield results which are not defined or in the wrong 
order of magnitude. In some cases, erroneous programs are actually danger- 
ous. The flight of the Ariane 5 space launcher ended in an explosion due to 
an input conversion function which could not cope with the large numbers 
(cf. [Nus97]). Some common programming errors, whose formalization will 
be sketched are 

• accessing a non-initialized array held; 

• accessing an element from an array with an index outside its bounds; 

• overflow / underflow of arithmetic operations. 

Some bugs can be avoided by switching to a safer language. In a perfect 
strongly typed language, the type carries all the information about the safe 
states and verification of type safety is done by the compiler. None of the 
strongly typed languages are considered perfect. Moreover, safer program- 
ming languages cannot prevent many other security bugs, especially those 
involving higher level semantics like the environment specific non-visible dis- 
play boundaries in Figure 4. The intention of this work is to provide a 
framework that allows to express and check domain-specific safety require- 
ments in addition to common runtime errors, especially those that can be 
expressed by finite domain constraints. 

The safety signature is an abstract description of the formal parameters 
for which syntax and semantic safety conditions can be given. It is defined 
by a list of type declarations for variables and requirements on calling con- 
ventions (like input-output arguments) to be obeyed by foreign applications. 

Firstly, the types of the safety specification shall be a subset of the pro- 
gram declaration. Program declarations are viewed as generic type decla- 
rations for which the actual safety interface description provides domain- 
specific instantiations. This requires a signature mapping from the program 
declaration to the actual signature of the safety specification. Consider for 
example the program declaration 

DECLSfinput : array (images ,gif , 2) , 
output: array (d_area, gif , 2) , 
local: scalar (i_width, integer) , 
scalar (i_height , integer) } 
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This could be translated into the safety signature 

VARS images : array (gif, *, 2) A djarea : array (gif, 2) A 

i -width : integer A i -height : integer. (1) 

The additional pre-condition below states that input values need to be ini- 
tialized prior to program execution. 

PRE 3 Xi n it[i\ : gif A access(images, i) = Xi n n A 0 < i < 2. (2) 

Secondly, there can be multiple possible signatures for the program code, 
each being a useful abstraction for validating particular safety requirements. 
The safety signature can augment the type specifications entailed in program 
interfaces. This could be necessary, for example, to analyze performance 
properties or consumption of resources. These properties can be security- 
relevant, however are typically not considered when proving functional cor- 
rectness. In the example discussed here, an additional context variable that 
maintains the dynamic coordinates of the “relative origin” for placing images 
is needed as part of the safety assertions, ie., 

POST = 3x : access(r el -origin, 0) = x A 3y : access(r el -origin , 1) = y (3) 

3.2 Safety Axioms 

A safety policy has to provide the axioms that hold taking into account 
the particular safety requirements. Safety axioms are a formal abstract de- 
scription of the data-representation axioms to be preserved in the specific 
environment such that the execution is considered to be safe. 

Overflow/ Underflow As Hoare points out in [Hoa69], infinite arithmetics 
satisfies -G xMy(y < x) where all finite arithmetics satisfy: Mx(x < max) and 
“max” denotes the largest integer represented. Furthermore, Hoare distin- 
guishes the three treatments of overflow 

-I3x(x = max + 1) (strict interpretation) 
max -1- 1 = max (firm boundary) 
max + 1 = 0 (modulo arithmetics) 

For example, the mathematical set of integers can be implemented in JAVA 
by the built-in integer data types byte, short, int, long which all have a 
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different, but finite range (cf. [BS02]). The actual behavior could also be 
based upon the computer architecture. In the remainder of this paper, it is 
supposed that the finite domain of integer values is constrained by a maximal 
and minimal bound, e.g.: 

i : integer 4= i > minint A i < maxint, minint = — 2 5 , maxint = 2 5 (4) 

Array Access (Multi-dimensional arrays) are axiomatized as an abstract 
data type array(r,e i), array(r,e i,e 2 ), . . ., array(r,e i, e 2 , . . . , e„), n E N, 
where r denotes the type of the array elements and e 1: e 2 , . . , e n its size. 
Arrays used in this paper are assumed to start at index 0, will be assigned 
values by the operation assign and can be accessed by the operation access. 

In the one-dimensional case, access and assignment on arrays satisfy the 
following axioms (cf. [LS79]): 

access(assign(a, j, expr ), i) = access(a, i) <= i ^ j. 

access(a, i) = expr <= i = j A assign(a, j, expr). 

access(a, j) = error. (5) 

Side Effects The coordinates of the relative origin change dynamically as 
result of assignments to the display area. There cannot be any side-effects in 
assertions. If Post denotes a state then select(Post, reLorigin) denotes the 
contents of reLorigin and update(select(Post, reLorigin ), assign{djarea h expr)) 
denotes the state obtained from reLorigin by assignment of expression to a 
held in d_area. 

3.3 Lifting Rules 

Regarding a basic imperative programming language, the semantic change 
of state is caused by the assignment operator and arithmetic operations. A 
generic verification condition generator is devised using the meta-predicates 
safe^assign , safejexpr to mark context-dependent verification conditions. 
safe -expr (expr) denotes the assertion that the evaluation of the symbolic 
expression expr must be safe, ie., according to the context-dependent typing 
axioms, the evaluation doesn’t cause an error for any admissible input. The 
generic safety condition safe-assign(lhs,rhs) is used to augment the orig- 
inal pre-condition of each assignment Ihs := rhs with the general meaning 
that the state after assignment is legal, provided that the statement before 
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is legal and taking into account side-effects. Domain-specific safety require- 
ments can be introduced by attaching finite domain constraints to the typed 
variables available in the program. Analyzing the scenario stated in Figure 3, 
for example, the absolute sizes of the domain-specific display area need to be 
taken into account for safety analysis. For example, the maximal allowable 
display area on specific laptops embraces 1024x768 pixel and the initial coor- 
dinates of a virtual origin could denote the supposed margin from the upper 
left corner. Applying the viewpoint concept (cf. [Eus99]), lifting rules are 
used to associate domain-specific requirements with generic problem solving 
steps. Figure 5 establishes the corresponding definitions. 


VARS 


INITIAL 

CONSTRAINTS 


UPDATE 


LIFTING 


images : array (gif ,2) A djxrea : array(gif, 2) A 
ijwidth : image-width A iJieight : image-height A 
d-h : display-height A d-W : display -weight A 
r el -origin : array {integer , 1). 
assign{rel -origin, 0, 50) A as sign{r el -origin, 1, 50). 
imagejwidth(x) -4= x : integer A x > 0 A x < 350. 
x : image-height - 4 = x : integer A x > 0 A x < 350. 
x : display -width - 4 = x : integer A 0 < x < 768. 
x : display -height -4= x : integer A 0 < x < 1024. 
i : integer -<= i > — 2 10 A i < 2 10 . 

update(select{Post, r el -origin) , assign{d-width, _, _)) = 
[assign{rel-origin, 0, access{r el -origin, 0) + i-width), 
as sign{r el -origin, 1, access{r el -origin, 1) + i-height)]. 
saf ejassign{i-width, expr) ■<= safe-expr{expr) A 
expr : image-width. 

saf e -as sign{i -height, expr) <= saf e-expr (expr) A 
expr : image-height. 

saf ejxssign(d-area,i, image, [expO, expl]) 4= 0 < i < 1 A 
expO : display-width A expl : display -height, 
saf e-expr (expr) ■<= -i (expr = error). 


Figure 5: Context-dependent Definitions for Generic Safety-predicates 
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4 Generic Safety Rules 

In [Fra96] the term verification conditions and the relation 

Post I - Q Pre 1 VCs 

is introduced with the following meaning: the post-condition Post is true 
after a terminating execution of the program Q 1 if the pre-condition Pre is 
true before executing the program, and if the set of verification conditions 
VCs contains only valid formulas. Based upon the Floyd-Hoare inductive 
assertion method, proof rules for the generation of verification conditions 
VCs are described. 

In this work, in addition to verification of functional correctness, the goal 
is to show that the execution of synthesized code is safe. A safety policy is 
specified by the viewpoint T sa f e and a set of safety rules. To achieve safety 
rules that allow the automatic computation of safety conditions, the above 
cited framework (cf. [Fra96]) for verification condition generation is extended. 
The relation 


Post b Q — > Pre A SafeExpr, VCs :: T sa f e 

is introduced with the following meaning: the post-condition Post is true 
after a terminating execution of the program Q 1 if the pre-condition Pre is 
true before executing the program, and if the set of verification conditions 
VCs contains only valid formulas. SafeExpr entails all values of program 
variables at intermediate stages during program execution are allowable, pro- 
vided that they comply with the requirements in T sa f e . 

The resulting modified proof rules to compute the weakest pre-condition, 
the safety expression and verification conditions are summarized in the sub- 
sections 4. 1-4.3. The VCGen does not depend on a particular safety theory 
T sa f e . T safe is a domain-specific safety interface as exemplified in the previ- 
ous section and provided by the code consumer. Subsection 4.4 states the 
rule to verify safety and functional correctness. 

4.1 Assignment 

Let P[x/expr\ denote the assertion that is like P except that expr has been 
substituted for the occurrences of x. 
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Variable Assignment 

Post b x expr — > Post[x/expr\ A 
safe.assign(x, expr)[] :: r sa/e 


Array Assignment 

Post b a[index\ := expr — > {Post[access(a, index) /expr]) A 
A saf ejassign{a, index, expr)}, \\ :: T sa f e 

4.2 Control Structures 

Skip 

Post I- skip — > Post , [] :: T sa f e 


Sequencing 

Post b STMT2 — > Pre 2, Conds 2 :: r sa j e 
Pre2 b STMTiPre, Condsi :: T sa j e 
Post b STMTi ; STMT 2 — > Pre,Conds\ U Conds2 :: T sa j e 


Conditional Statement 


Post b 


Post b STMTi — » Pre 1, Conds\ :: r sa j e 
Post b STMT2 — > Pre2,Conds2 :: T sa j e 
if B then STMTi else STMT 2 — * (P => Pre\) A (-1P =>• Pre 2), 
Conds 1 U Conds2 ■■ r sa f e 


While Loop 

Inr b STMT — >■ Pre, Conds :: T sa j e 
Post b while B inv{Inv} do STMT — » Inr, 

{/nr Ail4 Pre, Inv A -iP Post} U Conds :: r sa j e 

Assertions: Rules of Consequence 

Post b STMT — > Pre, Conds :: r sa y e 
Post b STMTPreAss — > PreAss, {PreAss Pre} U Conds :: r sa y e 

PostAss b STMT — » Pre, Conds :: T sa j e 
Post b PostAssSTMT — >■ Pre, {PostAss Post} U Conds :: T sa j e 



4.3 Extensions 

Iteration A way to get at a rule for FOR loops is to unfold the FOR into 
a loop body followed by a WHILE and then apply the WHILE rule and 
composition/consequence. This yields 


Inv[i + 1 /*] F STMT — > Pre, Conds :: T sa f e 
Post F for i : = e_0 until e_j inv{Inv } do STMT — > Inv[eJd/i\, 

{( Inv A (i < e_j)) => Pre),Inv A (i > e_j) Post} U Conds :: T sa f e 

Composition of Rules of Consequence 

Post Assert F STMT — > Pre, Conds :: T sa f e 
Post F PostAssertSTMTPreAssert — > {PreAssert}, 

{Post Assert =5 Post, PreAssert ^ Pre} U Conds :: T sa j e 

4.4 Verifying Consistency and Correctness 


Post F STMT — > SafeExpr A WPre , Conds :: T sa j e 
F Conds U {Pre =$■ WPre} 

^ safe I — '(3 x : -^SafeExpr(x) A ( WPre U Conds)) 
{Pre}Decls] ST MT{Post} :: T sa f e 

5 Automatization of Safety Certification 


5.1 Synthesis of Generic Safety Conditions 

The basic approach in this work to building a software component that au- 
tomatically extracts generic safety conditions from given programs, is to de- 
velop an appropriate meta-interpreter. Having derived the extended condi- 
tion generation rules (cf. Section 4), the implementation of a meta-interpreter 
that computes safety conditions is straightforward and sketched in Figure 6, 
implementing a subset of the verification rules assembled in section 4. In Au- 
toBayes, synthesized programs and its annotations are represented as ground 
terms. Assertions like pre-conditions, post-conditions, invariants and single 
program statements can be accessed through selector functions. The pred- 
icate scg is used to implement single relationships among program specifi- 
cations and safety conditions, according to the rules composed in Section 4 
and operates on the AutoBayes term representation of its objects. 
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Meta-interpreter 


Sorts : 
Variables : 

Operators : 
Goals 

Axioms 


progJerm , formula , set-of -formula 
WPre, Pre, Post : formula ; 

VCs : set-of -formula] Prog : prog -term, 
decomposejprog : prog-term — >■ prog-term x prog-term 
<- scg(+Post, +Prog , +Pre, — VCs) 
scgJ(+Post, +Prog , — WPre , —VCs) 


scg(Post, Prog, Pre, VCs) 4— scgji(Post, Prog, WPre, VCs J ) 

VCs = {Pre => TVPre} U VCs J. 

scgJ(Post, skip, Post, {}). Rule (8) 

scgJ(Post, Prog, WPre, VCs) 4- Rule (9) 

decompose(Prog, Last, Remainder ), 
scgJ(Post, Last, WPre i, VCondi) A 
s eg J (TV Pre\, Remainder, WPre, VCondjr)f\ 

VCs = Condi U Condjr. 

scgJ(Post,assign(LHS, RHS), WPre, VCs) 4- Rule (6) 

WPre = subs(Post, RHS = LHS) A safe-assign{LH S, RHS), 
scgJ(Post, for(idx(I, Begin, End), Stmt, Invariant), WPre, VCs) 
Invlterate = Inv[I + 1/7], 
scgj(lnvlterate, Stmt, WPre, VC), 

InvBegin = Inv[Begin/ 1], 

VCs = {{{Inv A (7 < Pn<j) => WPre), 

(7m> A 7 > (Pnc? + 1)) => Post} U VC. 


Figure 6: Automatic Synthesis of Generic Safety Conditions 


The execution of the meta-interpreter, given a program specification as 
input, is as follows: 

• It works backwards through the program statement by statement ap- 
plying the sequence rule for splitting a list of statements into the last 
statement and remainder list of statements and subsequently processes 
the single statement and the remainder list of statements. 

• At each intermediary point, it tries to find a matching rule that gener- 
ates the actual verification conditions, the weakest pre-condition, the 
safety expressions and subgoals. 
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• Finally, the condition that the actual pre-condition implies the weakest 
pre-condition is added to the set of verification conditions. 

The process of safety condition generation is independent of the particu- 
lar safety policy or logic used. Applying the meta-interpreter to the example 
program of Figure 3 generates the verification conditions and safety expres- 
sions as shown below. 

5.2 Simplification 

The process of synthesizing proof obligations is independent of the partic- 
ular safety policy or logic used. The proof obligations have two separate 
conjuncts, one for functional correctness and another for the generic safety 
obligations. When verifying safety and correctness properties, fully auto- 
matic analysis is in general not feasible as it involves reasoning about arrays 
with mixed symbolic and numerical indices, type checking and arithmetics 
which in general is undecidable. Classical theorem provers are not well suited 
to symbolic arithmetic calculations which naturally arise from considerations 
about safety of program executions. Therefore, we are looking for simplifica- 
tion and reduction techniques that enable us to automate some proof steps 
and to solve the others interactively. The basic idea is to partition the safety 
and verification conditions into classes for which decision procedures and as- 
sociated simple tool support exist and to analyze extensible sets of safety 
properties successively. If invariants, pre- and post-conditions are restricted 
to unquantified propositional formulas over algebraic expressions, combined 
by the usual connectives, then the simplification strategy could be based on 
the use of a computer algebra system. Computer algebra systems integrate 
features that are based on first-order equational logic to implement its evalu- 
ation mechanism. Standard facilities are substitutions and pattern matching 
in a wide variety of forms, automatic and user controlled simplification of 
arithmetic expressions and symbolic calculations involving operations on ar- 
rays and matrices. Moreover, they provide simple type checking procedures. 

Substitution applied to the generated proof obligations and simplifying 
the expressions with the general data type axioms, cf. equations (1), (2), (3), (5), 
generates the following safety expression: 

saf e_assign(i_width, 300) and saf e_assign(i_height , 350) and 

exists(y, r_origin[l] + 1050 = y) and exists(x, r_origin[0] + 900 = x) and 

saf e_assign(d_area(0) , im2, r_origin[0] + 300, r_origin[l] + 350) and 
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saf e_assign(d_area(2) , imO, r_origin[0] + 600, r_origin[l] + 700) and 
saf e_assign(d_area(l) , iml, r_origin[0] + 900, r_origin[l] + 1050) 

In other words, the program is correct with respect to its pre- post-conditions. 


5.3 Domain-specific Safety Checking 

Generally, in order to verify safety of program execution, taking into account 
its environment, it needs to be shown that all generic safety conditions follow 
from the actual safety specification T sa f e . 

r sa f e I — i(Ete : -i SafeExpr(x) A WPre U Conds) 

Considering this particular example, it only needs to be shown that 

r sa / e b “'(3a; : ~^SafeExpr(x )), 

where r sa j e is a domain-specific safety viewpoint as exemplified in Figure 5 
and generally provided by the code consumer. A formal proof then essen- 
tially constitutes a formal statement that the program, when executed, will 
not violate any safety properties. Possible proof strategies are to use stan- 
dard algorithms which are implemented in theorem provers or to submit 
specific proof obligations to specific tactics as the Omega solver. The Omega 
library is a set of routines for manipulating linear constraints over integer 
variables, Presburger formulas, and Integer tuple relations and sets [Pug92]. 
Constraint-logic programming combines the advantages of declarative logic 
programming with efficient constraint solving. It seems to be the most ade- 
quate choice to automate verification of the generated and simplified safety 
conditions. Implementing the domain-specific safety viewpoint r sa / e specified 
in Figure 5 using a constraint-logic programming language and submitting 
the simplified safety expression automatically yields the result no. It corre- 
sponds with the obvious fact that the program execution is unsafe, taking 
into account the particular safety requirements modeled as finite domain- 
constraints. 


6 Related Work 

Numerous research systems allow the certification of compiled code of platform- 
dependent safety properties such as stack safety, accessed memory regions 
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and control flow safety based upon appropriate type systems. The pre- 
sented framework adopts ingredients from Necula’s and Lee’s approach (cf. 
[Nec97, NL98]) for proof-carrying code, but in this work safety properties 
can be analyzed on a higher code level than assembly language instructions 
through generic safety types. Touchstone is a compiler that translates pro- 
grams written in a type-safe subset of the C programming language into as- 
sembly language programs, and a certifier that automatically checks the type 
safety and memory safety of the produced program. A verification condition 
generator produces a safety predicate for each function. The method ap- 
plied combines forward symbolic evaluation and verification condition gener- 
ation in contrast to the standard backward analysis for verification condition 
generation. The certifier performs further optimizations like array bounds- 
checking elimination. 

Coq (cf. [FM99]) is a system for specifying and certifying imperative 
programs. The programs are given in an ML-Pascal like intermediate code 
mixing imperative features (references, arrays, while loops, sequences) and 
functional features. They are specified in a Floyd-Hoare logic style, by in- 
sertion of logical assertions, such as pre-conditions, post-conditions and loop 
invariants. Termination is justified by the insertion of a pair variant /relation 
associated to each loop or recursive function. Then an automatic tactic takes 
a specified program and produces some proof obligations, whose validity im- 
plies both correctness and termination of the initial program. 

[CWOO] presents a type system for specifying bounds on resource bound 
consumption and a method for certifying those bounds by considering cost 
functions. They provide a compiler generating certified executables from 
source code. [LPR01] uses abstract interpretation for proving consistency 
of higher-level domain-specific properties to a safety policy. Membership 
equational logic is used as logical framework for automated verification of 
frame safety properties. 

A number of static analysis and certification approaches formulate verifi- 
cation problems as systems of symbolic and numerical constraints. [WFBAOO] 
regards the detection of buffer overruns as an integer range analysis problem. 
[CKX01] combines a forward analysis to infer constraints at designated pro- 
gram points and a backward method for deriving a safety pre-condition. The 
derived pre-conditions are used for eliminating partially redundant checks 
and program optimization. Calculations are performed using the Omega 
library. [XMROO] presents a safety-checking analysis technique that only re- 
quires that the initial inputs to the untrusted program be annotated with 
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typestate information and linear constraints. Polyspace is a commercial tool 
that allows the automatic detection of common programming errors for C 
code at compilation time. Based on abstract interpretation it detects com- 
mon programming errors as for example “out of bounds array index” , “unini- 
tialized variable” , “division by zero” , “overflow” or “underflow” . 


7 Conclusions 

This paper has provided a new three-stage framework towards the certifi- 
cation of simple imperative programs annotated with loop invariants, pre-, 
and post-conditions. An extension of the Floyd Hoare verification framework 
allows the automatic computation of generic safety conditions for annotated 
imperative programs and taking into account side effects. A corresponding 
meta-interpreter has been devised. Viewpoints assemble particular domain- 
specific safety requirements in terms of the generic safety predicates. The 
proof of the generic safety conditions, having provided a particular viewpoint 
as context, ensures safety of program execution at all intermediate states in 
a particular environment. 

In a former version of AutoBayes, the safety policy was hard-coded in the 
way the annotations were generated within the synthesis schemas. The code 
was annotated to prove division- by-zero and array-bounds safety (cf.[FS02]) 
and then a verification condition generator was used for creating verification 
conditions which are resolved by a theorem prover. The advantage of sep- 
arate and dynamic safety viewpoints is that the designer or the synthesis 
system need not add all the safety-related assertions to the program or syn- 
thesis schemes thus making it less cluttered and easier to make type-related 
changes to the safety policy. By this way, certificates are by comparison rel- 
atively compact, easy to produce and to verify. The architecture facilitiates 
synthesis of certified software from libraries of re-usable components and 
safety theories. Particular safety requirements can be represented exactly 
and explicitly as separate theories using and refining definitions entailed in 
standard libraries. Generic safety conditions for annotated programs need 
to be generated only once. When changes are made to the safety require- 
ments, there is no need for a full re-verification of the program to prove that 
these changes don’t effect the safety of program execution. It only needs to 
be shown that the generic safety conditions are consistent with the actual 
safety theory. 
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Although this work explores in detail only rather simplified contextual 
safety constraints, it is believed that the approach developed so far provides 
a framework that will be applicable to the formal treatment of a much wider 
variety of semantic safety properties like general resource constraints. To en- 
able these kinds of domain-specific safety checks, the safety viewpoint would 
augment the program declarations and entail more complex safety axiomati- 
zations. 
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